Summary An Emirates-based marine services firm running Microsoft Dynamics 365 Business Central found that an approved purchase order had disappeared, along with every record of who approved it. We confirmed the order had been deleted rather than archived, showed why Business Central removes approval entries together with the document, and identified the likely approvers from the approval chain. We then explained how a point-in-time restore of Production into a sandbox recovers the actual approval history, set up the change log so future deletions are recorded in full, and recommended controls that stop approved documents from being deleted at all. Table of Contents Introduction Understanding the Issue Deleted or Archived? How We Confirmed It Why the Approval Entries Disappeared Reconstructing the Likely Approvers Recovering the Evidence with a Point-in-Time Restore Making Future Deletions Traceable Preventing Approved Documents from Being Deleted Business Impact Frequently Asked Questions Conclusion Introduction Approval workflows in Microsoft Dynamics 365 Business Central give finance teams confidence that every purchase order was reviewed before it went to a vendor. That confidence depends on one assumption: the approval history will still be there when someone needs it. For an Emirates-based marine services firm we work with, that assumption broke. The finance team went looking for a released purchase order and could not find it. When they checked Approval Entries, there was nothing there either. A few days later, two purchase invoices were deleted as well, and the change log had no record of them. 1 Approved purchase order missing 0 Approval entries left for it 28 Days available to recover the evidence This post walks through how we investigated the issue, what Business Central does behind the scenes when a document is deleted, and the setup that makes every future deletion traceable. The Lesson In Business Central, deleting a document also deletes its approval history. Audit trails have to be set up before they are needed, not after. Understanding the Issue The finance team came to us with three questions. Each needed a clear, evidence-based answer. 01 Was It Deleted or Archived? The order was in Purchase Order Archives, so it looked as if someone had simply archived it by hand. 02 Who Approved It? The order had been released through an approval workflow, but Approval Entries showed nothing for it. 03 Why Was Nothing Logged? The change log had just been switched on, yet the invoices deleted afterwards left no trace in it. Deleted or Archived? How We Confirmed It Archiving and deleting both leave a copy in Purchase Order Archives, so the archive alone does not tell you what happened. The difference is what remains in the live system. Archived Archive Document A copy is saved to Purchase Order Archives, but the original order stays in the Purchase Orders list, together with its approval entries. Deleted Delete The order leaves the Purchase Orders list. If Purchases & Payables Setup is set to archive orders, Business Central saves an archive copy automatically at the moment of deletion. We worked through the possibilities one at a time: How we ruled out each possibility Not in Purchase Orders → No Receipts, Invoices or G/L Entries → Only in Archives → Version No. 1 → Deleted The Version section of the archived order settled it: Version No. 1: only one archived version existed, so the order had never been archived by hand. This version was created when the order was deleted. Archived By: the user ID that deleted the order. Date and Time Archived: the exact moment of deletion. Figure 1: The archive version details show who deleted the order and when. Why the Approval Entries Disappeared Approval entries are linked to the document they belong to. When the document is deleted, Business Central deletes its approval entries too. The archive keeps the order’s header and lines, but not its approval history. To show this to the client with evidence rather than theory, we reproduced it on a copy of Production using an older released order: 1 Released Order We picked a purchase order that had been released through the approval workflow. 2 Approvals Recorded Its Approval Entries showed three approvals from three different approvers. 3 Order Deleted After the order was deleted, Approval Entries showed nothing for it. 4 Archive Copy Remains The order was still available in Purchase Order Archives, without its approvals. Figure 2: Before deletion, the test order carries its full approval history. Figure 3: After deletion, the approval entries are gone, even though an archive copy exists. Key Insight Purchase Order Archives answer what the order looked like. They do not answer who approved it. Once a document is deleted, that question can only be answered from a backup. Reconstructing the Likely Approvers With the approval entries gone, we looked at the next purchase order raised by the same user. Approvals follow the approver chain set up in Approval User Setup, so an order from the same requester with a similar amount follows the same route. Step Role What Happens 1 Requester Raises the purchase order and sends it for approval 2 First approver Next user in the requester’s approver chain 3 Second approver Next user in the chain, based on the approval limits A Reconstruction, Not a Record This identifies the most likely approvers, but it is not proof. It assumes the approval setup has not changed since, and that the deleted order’s amount did not cross a limit that would have added another approver. Recovering the Evidence with a Point-in-Time Restore Business Central Online lets you restore an environment to any point in time within the last 28 days. A Production environment can be restored as a new sandbox, which leaves Production untouched. In that copy, the deleted order still exists with all its approval entries. Steps We Recommended In the Business Central Admin Center, open the Production environment and choose Restore. Pick a point in time a few minutes before the deletion. Convert the archive’s timestamp to the time zone the Admin Center … Continue reading Recovering Lost Approval History After a Purchase Order Deletion in Business Central →

Summary For Emirates Consortium, an Abu Dhabi-based diversified holding company already using Microsoft Dynamics 365 Business Central across multiple legal entities, intercompany accounting is a relevant process area. This article explores how standard intercompany functionality can simplify transactions between related companies. It covers intercompany partner relationships, customer and vendor links, and G/L account and dimension mappings. Using practical scenarios, we walk through a sales invoice raised in one company and received as a purchase invoice in another, as well as journal-based allocation of partial expenses. The walkthrough also shows how the Intercompany Outbox and Inbox support transaction review before posting, and highlights key reconciliation controls and limitations. Table of Contents Introduction The Business Problem The Solution Implementation and Process Walkthrough Limitations and Key Considerations Business Impact Frequently Asked Questions Conclusion Introduction Organizations operating through multiple legal entities often share resources, incur costs centrally, and recharge expenses to the company that actually benefits from them. Although these entities belong to the same business group, each company maintains its own accounting records, receivables, payables, and financial reporting. Emirates Consortium LLC is an Abu Dhabi-based diversified holding company with businesses across the UAE and Maldives. As highlighted in the Emirates Consortium customer success story, CloudFronts deployed Dynamics 365 Business Central across five legal entities to support core business processes. For organizations operating across several companies, intercompany recharges and cost allocation are important areas to assess when looking to reduce duplicate finance work. To explore these capabilities, consider two related companies, Gulf Aquaculture (GA) and Gulf Aquaculture Alliance (GAA). The walkthrough covers two practical routes: an intercompany sales invoice for a formal recharge and an intercompany general journal for direct cost allocation. It explains the setup, accounting impact, and important control points involved in both processes. Route A Intercompany Sales Invoice A formal recharge from GA, received in GAA as a purchase invoice. Route B Intercompany General Journal A direct allocation of part of a cost already recorded in GA. The Business Problem The finance team managed transactions for separate group companies, but some costs, such as consultancy, administration, payroll-related expenditure, and project-related operating expenses, were initially incurred or recorded in GA even when they partly or entirely related to GAA. For example, GA might receive an external vendor invoice for AED 10,000, of which AED 4,000 is attributable to GAA. Without a standard cross-company workflow, staff must determine the chargeable amount, prepare a corresponding transaction in the second company, and verify that the two sets of books agree. 10,000 AED external vendor invoice recorded in GA 4,000 AED attributable to GAA 6,000 AED that remains GA’s own cost Handling this manually created five gaps: 01 Manual Re-Entry Re-entering transactions increased the risk of inconsistent amounts, descriptions, or account classifications between companies. 02 Hidden Costs The receiving company needed visibility into its own project and operating expenses rather than having those costs remain embedded in GA. 03 Limited Control Finance required control over which transactions were sent, accepted, and posted, particularly for higher-value recharges. 04 Different Account Structures The chart of accounts and dimensions needed to translate correctly when the two companies used different codes or reporting structures. 05 Month-End Reconciliation Intercompany balances needed to be traceable and reconcilable at month-end. Business Objective Record the charge once in the initiating company, communicate it through Business Central, and let the receiving company review and post the corresponding entry in its own books. The Solution The proposed approach used standard Business Central intercompany functionality rather than a separate custom integration. Both companies were configured as intercompany partners, with mapped accounts and dimensions to support the exchange of transactions. 1. Establishing the Intercompany Relationship Each participating Business Central company needs its own Intercompany Setup and a unique IC Partner Code. The other company is then added as an intercompany partner with an appropriate transfer method. For a partnership inside the same Business Central environment, direct company-to-company transfer can be used where supported by the configured environment. 2. Connecting Customers and Vendors In GA, GAA is represented by an intercompany customer for billing. In GAA, GA is represented by an intercompany vendor for recording the payable. Assigning the relevant IC Partner Code on the customer and vendor records connects the commercial documents to the receiving company. In GA Customer card GAA as an Intercompany Customer Used to bill GAA. The IC Partner Code links the invoice to GAA. In GAA Vendor card GA as an Intercompany Vendor Used to record the payable to GA. The IC Partner Code links it back to GA. 3. Mapping the Intercompany Chart of Accounts Business Central uses a shared intercompany chart of accounts as the language between companies. Each company maps its own G/L accounts to the intercompany accounts and maps incoming intercompany accounts back to its local G/L accounts. When account numbering differs between companies, these mappings are essential. During the walkthrough, the team reviewed how a sales invoice line could carry an IC Partner Reference so that the receiving company would recognize the appropriate expense account. Account mapping in both directions was especially important: an account existing in one company does not guarantee that the other company can post it. 4. Preserving Dimensions and Project Context Intercompany dimensions can transmit reporting context such as Department, Project, or Cost Centre when corresponding dimension codes and values are set up and mapped. The accounting team should confirm that the receiving company’s dimension values accurately represent the destination project or department. 5. Choosing the Appropriate Transaction Route Business Requirement Recommended Standard Route Formal charge for services or reimbursable costs GA intercompany Sales Invoice → GAA Purchase Invoice Partial allocation of an expense already recorded in GA Intercompany General Journal → corresponding journal in GAA Direct allocation while registering an external vendor invoice Purchase Invoice cost-allocation fields for IC Partner, where applicable and tested Correction of an earlier intercompany charge Appropriate credit memo or reversing journal, reviewed in both companies The following walkthrough focuses on the first two routes: intercompany invoices and intercompany … Continue reading How an Abu Dhabi-Based Diversified Holding Company Simplified Intercompany Transactions in Dynamics 365 Business Central →

Summary Connecting Dynamics 365 Project Operations with Business Central creates a continuous data journey from project planning and execution to financial visibility. Project and task information, planning lines, time, materials, expenses, billable values, and invoices must retain their identity and meaning as they move between systems. This implementation focuses on preserving those relationships so that Budget, Actual, Billable, and Invoiced values remain traceable and meaningful throughout the project lifecycle. The result is an integration that does more than synchronize records: it creates a reliable data story that supports project operations, ERP processes, financial analysis, and decision-making. Table of Contents Why Project Data Needs a Journey The Data Journey Entity-to-Entity Mapping Planning Lines Budget vs. Actual vs. Billable vs. Invoiced Execution and Project Journals From Activity to Invoice The Analytics View Implementation Lessons Conclusion The Project Does Not Live in One System Project Operations is where teams plan and manage project work. Business Central is where the project becomes part of an ERP financial workflow. The interesting part is the space between them. When the same customer, project, task, resource, or transaction crosses that boundary, the integration has to preserve more than a name. It has to preserve relationships and translate the source record into the target system’s business model. The Engineering Question “Did the record sync?” is only the first question. “Does the record still mean the same thing?” is the engineering question. CRM Project Operations Where the Project Is Planned Customer, project, tasks, resources, estimates, time, and project activity are planned and managed here. ERP Business Central Where the Project Becomes Financial Project tasks, planning lines, journals, invoices, and financial visibility form the ERP financial structure. CRM side Figure 1: A Project Operations project with stages, customer, dates, estimates, and project context. ERP side Figure 2: The corresponding project structure in Business Central. A Different Way to Look at the Integration Think of It as a Data Pipeline Source entities become mapped entities, mapped entities become ERP records, and ERP records eventually become transactions and financial metrics. How a record moves between the two systems Project Operations projects · tasks · resources → Mapping Layer identity · transformation → Business Central projects · planning lines 01 Plan Estimates, tasks, resources, and planned quantities describe what the project is expected to consume. 02 Execute Time, materials, and expenses create operational evidence of what happened. 03 Bill Billable value moves toward invoicing, turning project activity into commercial output. Entity-to-Entity Mapping Is Where Meaning Gets Preserved One of the most important parts of a Project Operations to Business Central integration is deciding what a source entity becomes in Business Central. The mapping is effectively a semantic contract. Project Operations Business Central Why It Matters Account (Customer) Customer Customer identity must remain consistent across systems Project msdyn_project Project / Job The project becomes the parent financial structure Project Task msdyn_projecttask Project Task / Job Task Task identity is required for planning and transaction attribution Estimate msdyn_estimateline Job Planning Line Planning becomes a structured Business Central financial planning record Time Entry msdyn_timeentry Project Journal Recorded effort can become project usage Figure 3: Account data flowing into Business Central as a customer, carrying its identity across the boundary. Planning Lines Are the Semantic Bridge Planning lines sit at the point where a project plan starts becoming an ERP financial model. In Business Central, planning lines can represent planned cost, billable value, or both, depending on how they are configured. That makes them especially important when explaining the transition from “what we intend to do” to “what the ERP expects this project to cost or generate.” Quantity How much work, material, or resource usage is expected? Unit Cost / Price What cost or commercial rate is associated with the planned quantity? Total Cost / Price The planning line turns quantity and rates into project-level financial expectations. CRM side Figure 4: The work breakdown structure decomposes project work into manageable tasks. ERP side Figure 5: Resource assignments become structured planning lines in Business Central. The Four Numbers People Confuse Most These values answer different questions. Treating them as interchangeable is one of the fastest ways to misread a project dashboard. 01 Budget: What Did We Expect to Spend? Budget represents planned cost. It is a planning value, not proof that the cost has already occurred. 02 Actual: What Cost Was Recorded? Actual (usage) cost is tied to execution and recorded project usage. A blank actual does not mean the budget disappeared; it means no actual usage has been recorded in that context. 03 Billable: What Value Can Be Charged? Billable represents chargeable project value according to the project’s planning and billing configuration. 04 Invoiced: What Has Actually Been Billed? Invoiced is downstream of billable value. A project can have billable value before the corresponding amount has been invoiced. The Simplest Mental Model Budget → Actual answers the cost question. Billable → Invoiced answers the revenue and billing question. Figure 6: Project budgeting concepts in Project Operations (source: Microsoft Learn). Execution Creates the Evidence Once the project moves from planning into execution, operational records begin to tell the story of what actually happened. Time entries, material usage, and expenses are examples of records that contribute to project actuals and downstream ERP transactions. What feeds the project journal Time hours worked + Materials items consumed + Expenses project spend → Project Journal CRM side Figure 7: Time entries recorded against projects and tasks. ERP side Figure 8: Approved time entries represented in the Business Central project journal. Figure 9: Material usage follows the same project-to-ERP transaction path. Engineering Insight An integration should be traceable backwards. If a number appears in an ERP report, you should be able to explain which transaction produced it and which project and task it belongs to. From Project Activity to Invoice The final part of the journey is commercial. Billable project data eventually feeds invoicing, creating a visible chain from planned work to customer-facing financial output. 01 Project Activity Time, materials, expenses, and … Continue reading From Project Operations to Business Central: Following the Data Behind Project Financials →

Summary For a Maldives-based marine services firm running Microsoft Dynamics 365 Business Central across multiple operating sites, item journals are used to record consumption and disposal of inventory such as diving and water sports equipment, consumables, and spares. The standard item journal does not stop a user from consuming or disposing more than is physically available at the selected location, because the item lookup and the Inventory figure reflect stock across all locations. In this implementation, we restricted item visibility and quantity validation to the location selected on the journal line. Users must select the location first, the item lookup shows only items with stock at that location, and the quantity is validated both when the line is entered and again at posting. We also carried the location onto the Item Journal Batch so that approval workflows can be routed per location. Table of Contents Introduction Understanding the Business Requirement The Challenge with Standard Item Journals Filtering the Lookup vs. Validating the Line Designing the Solution Filtering the Item Lookup by Location Validating Quantity at Entry and Posting Routing Approvals by Location Implementation Approach Business Impact Frequently Asked Questions Conclusion Introduction Many organizations running Microsoft Dynamics 365 Business Central hold the same items across several locations: properties, stores, warehouses, or project sites. Day-to-day consumption and disposal of that stock is usually recorded through item journals. Consider a storekeeper who opens the item journal to record the use of cleaning supplies. Business Central tells her one thing; her storeroom tells her another. 200 Units shown in Business Central 60 Units on her own shelf 140 Units at other locations Without additional controls, nothing prevents her from posting 100 units from her location. The journal accepts it, the location goes negative, and the difference only surfaces during stock counts or month-end reconciliation. This was the challenge for a Maldives-based marine services firm we worked with. Its sites are spread across separate islands, so equipment and consumables held at one site cannot simply be used at another. We addressed this with one rule enforced at every step: The Rule A user can only consume or dispose of what is physically available at the location they selected. Understanding the Business Requirement Before writing any code, we agreed the expected behavior with the client as concrete scenarios. Each scenario later became a test case for user acceptance testing. Scenario 1 Item Stocked Across All Locations Cleaning concentrate. User selects Location A. Location A60 Other locations140 Company total200 Shows 60 available. Entering 100 is blocked. Scenario 2 Item Available at Several Locations Snorkel mask. User selects Location A. Location A30 Location B5 Location C21 Location D10 Shows 30 available. Other locations are ignored. Scenario 3 No Stock at the Selected Location Kids’ snorkel set. User selects Location D. Location A10 Location B0 Location C0 Location D0 Not available. Consumption and disposal are blocked. From these scenarios, we derived three key requirements: Show only the items and quantities available at the selected location. Prevent any consumption or disposal quantity greater than the location’s available stock. Route approvals to the person responsible for that location. The Challenge with Standard Item Journals Standard Business Central treats the item journal as a general-purpose adjustment tool, and it trusts the user. For businesses with stock spread across sites, three gaps follow from that. 01 Lookup Shows Company-Wide Stock The Inventory figure on the Item List is the total across all locations unless a location filter is applied. A user sees 200 when only 60 is on their shelf. 02 Location Is Just Another Field Users can select the item first and the location later, or leave it blank, so the system has no location context when the item is chosen. 03 Quantity Isn’t Checked by Location Prevent Negative Inventory is often switched off, only triggers at posting, and gives a storekeeper little guidance. Figure 1: The standard item lookup shows total inventory across all locations, not the stock at the user’s location. Key Design Consideration Location needed to be the starting point of every consumption and disposal line, not an optional detail added afterwards. Filtering the Lookup vs. Validating the Line The first instinct is to filter the item lookup by location. That is useful, but it is not a control on its own. Guides Lookup Filtering Points the user to the right items. It does nothing when someone types an item number directly, pastes lines, or uses Edit in Excel. Enforces Validation Runs whenever the field changes, however the value arrives. Every rule shown in the lookup needs a matching check in table validation and at posting. How a consumption or disposal line moves through the checks Select Location → Item Lookup at Location → Entry Check → Posting Check → Line Posts Designing the Solution We reduced the requirement to four rules that apply to every consumption and disposal line. 1 Location First The user must select the Usage Location Code before the Item No. field becomes editable. The location carries over to the next new line. 2 Show Only What Is There The item lookup lists only items with stock above zero at the selected location, with that location’s quantity. 3 Never More Than Is There The quantity cannot exceed available stock at the location, after subtracting other unposted lines for the same item. 4 Check Again at Posting Stock can change between entering and posting a line, so the same rule runs again just before each line posts. Figure 2: Usage Location Code must be selected before the Item No. field becomes editable. Together, these rules form three layers of control: Layer 1 · Lookup Guides the user to items in stock at the selected location. Layer 2 · Entry Check Blocks over-consumption as soon as the line is entered. Layer 3 · Posting Check Confirms availability against live stock before posting. Filtering the Item Lookup by Location Business Central already calculates stock per location. The Inventory field on the Item table is a FlowField that … Continue reading Location-Based Item Based Visibility in Business Central for a Maldives-Based Marine Services Firm →

Summary Project-based organizations often manage project delivery in Microsoft Dynamics 365 Project Operations while relying on Microsoft Dynamics 365 Business Central for finance, purchasing, inventory, and accounting. Without a connected process, project teams and finance teams can end up working with different versions of the same information. CloudFronts built an integration between Project Operations and Business Central using Dataverse plugins. Instead of relying on users to manually recreate records, the integration responds to important Project Operations events and sends the relevant data to Business Central through web services. It covers customers, projects, timesheets, expenses, invoices, and inventory availability, writes the Business Central identifier back to the originating Project Operations record, and captures failed transactions in an Error Log for troubleshooting. Table of Contents The Project Integration Challenge Our Integration Architecture Keeping Project Customers in Sync Connecting Projects to Business Central Synchronizing Timesheets Moving Project Expenses into Finance Connecting Project Invoices End-to-End Project Integration Flow Business Benefits Key Implementation Considerations Frequently Asked Questions Conclusion About the Example in This Post To show how the integration behaves end to end, the screenshots use a sample customer, Westview Ltd, and its project, Westview-Project-003. These are sandbox records used purely to demonstrate the data flow between Project Operations and Business Central. The Project Integration Challenge Project-based businesses have a unique challenge: the people delivering the project and the people managing its financial impact often work in different systems. Project Operations can be the place where project teams manage customers, projects, resources, tasks, time, expenses, and project billing. Business Central, meanwhile, can be responsible for financial management, purchasing, inventory, and other ERP processes. When these systems are not connected, the same project information may have to be entered more than once. A project manager may record time in Project Operations while finance needs the same information in Business Central. A project invoice may be created in one system while the corresponding financial information needs to be reflected in another. The Core Problem Project teams need to work in the system designed for project delivery, while finance needs accurate and timely information in the ERP. Manual re-entry creates extra effort, delays, and opportunities for data inconsistency. The objective of the integration was therefore not simply to move records between two applications. It was to connect the project lifecycle with the corresponding Business Central processes. Our Integration Architecture The integration uses Dataverse plugins as the event-driven layer connecting Project Operations with Business Central. A Dataverse plugin is a piece of C# code that runs when a Dataverse record is created, updated, or otherwise processed. This provides an opportunity to respond to project-related events and send the relevant information to Business Central. High-Level Flow A user creates or updates a project-related record in Project Operations. The corresponding Dataverse event triggers the plugin. The plugin reads the required information from Dataverse. The data is transformed into the structure required by Business Central. The plugin calls the relevant Business Central web service. Business Central creates or updates the corresponding record. The Business Central identifier is written back to the Project Operations record where required. If the request fails, the integration captures the error and the data involved in an Error Log. Why an Event-Driven Approach? The integration reacts when project information changes, instead of depending on users to remember when and where the same information must be entered. Figure 1: High-level architecture of the Project Operations to Business Central integration. Keeping Project Customers in Sync Customers are a fundamental dependency for project processes. Before project transactions can be represented correctly in Business Central, the corresponding customer needs to exist there. When a customer is created or processed in Project Operations, the integration sends the relevant customer information to Business Central. What the Integration Achieves 01 Create or Sync Creates or synchronizes the customer in Business Central. 02 Map the Fields Uses the appropriate source-to-target field mapping. 03 Capture the Number Captures the Business Central customer number. 04 Write It Back Writes the Business Central identifier back to the originating record where required. This creates an important link between the two systems. The Project Operations record retains the Business Central number, so users do not have to search manually for the corresponding ERP record. In our example, Westview Ltd is created as an account in Project Operations. The integration synchronizes it to Business Central and writes the resulting Business Central customer number (C00280) back onto the Project Operations record. Figure 2: Westview Ltd in Project Operations, with the Business Central customer number (C00280) written back to the int_sourceid field. Figure 3: The corresponding Westview Ltd customer record (C00280) synchronized into Business Central. Connecting Projects to Business Central Customer synchronization is only the beginning. The central object in a project-based integration is the project itself. When a project is created or prepared for synchronization, the integration retrieves the project information required by Business Central and creates the corresponding project record. It then maintains the relationship between the Project Operations project and the Business Central project using the relevant identifiers. Why Project Identifiers Matter A Project Operations record may contain Dataverse identifiers and lookup references, while Business Central works with its own project numbers. These identifiers cannot simply be assumed to be interchangeable. The integration needs to resolve the correct project identifier and use it when subsequent project-related transactions are sent to Business Central. Project Integration Principle Synchronizing a project is not only about copying project fields. It establishes the reference that later transactions, such as time, expenses, materials, and billing, use to reach the correct Business Central project. Continuing the example, Westview-Project-003 is created under Westview Ltd in Project Operations. The integration creates the matching project in Business Central and writes the Business Central project number (PR00340) back to the int_sourceid field on the Project Operations record. Figure 4: Westview-Project-003 in Project Operations, with the Business Central project number (PR00340) written back to int_sourceid. Figure 5: The corresponding Project Card (PR00340) for Westview-Project-003 in Business Central. Synchronizing Timesheets Time is one … Continue reading How to Integrate Dynamics 365 Project Operations with Business Central Using Dataverse →

One Data Platform, Future-Ready for AI – Power BI Report Migration to Azure Databricks Summary Every organization wants to be AI-ready. Very few are data-ready. Business data typically lives across ERP, CRM, HR, and finance systems, each handled differently and reported separately. The result is familiar to most leadership teams: reports that do not agree, logic rebuilt in every dashboard, and AI initiatives that stall because the data underneath them cannot be trusted. This article makes the case for one data platform – a single, governed foundation where all business data is brought together, processed consistently, and made ready for both reporting and AI. We share how we built this at CloudFronts on Azure and Databricks, unifying five business systems and migrating 40+ Power BI reports with zero downtime, and why that foundation is what makes AI use cases practical rather than aspirational. Table of Contents 1 The Hidden Cost of Scattered Data 2 What One Data Platform Really Means 3 Why It Matters to the Business 4 Solution Architecture Overview 5 Migration Without Disruption 6 From Reporting Platform to AI Foundation 7 AI Use Cases It Unlocks 8 Scattered vs Unified 9 Questions Every Leader Should Ask 10 Where to Start 11 FAQs 12 Conclusion The Hidden Cost of Scattered Data Most growing organizations do not set out to fragment their data. It happens one decision at a time. A new ERP for finance. A CRM for sales. An HR system for people. An accounting tool for a specific entity. Each one solves a real problem – and each one becomes another separate source of data. This project started with our own reporting. Like many growing services organizations, CloudFronts runs its business across several systems: Business Central and Finance & Operations for ERP, Dynamics 365 CRM for clients and engagements, Zoho People for HR, and Zoho Books for accounting. Leadership, finance, HR, and delivery teams rely on more than 40 Power BI reports built on these systems, from management dashboards and HR reports to the Steering Committee report we use to track quarterly meetings with client accounts. Over time, each system had been connected in its own way. Some data moved through Azure Data Factory, some through SQL Database, and some through Azure Functions. Reports connected directly to their sources, with business logic built inside each one, and they sat across separate workspaces for HR, management, and other teams. The idea behind the project was simple: instead of continuing to add pipelines and reports system by system, bring all business data into one trusted platform on Azure Databricks, migrate every existing report onto it without disrupting the people who use them, and build a foundation that is ready for AI in the process. None of the old setup looked broken on any given day. But the costs were real, and they compounded as the business grew. Numbers That Do Not Agree When the same metric is calculated in several reports, small differences appear. Leadership meetings start with reconciling numbers instead of acting on them. Effort That Keeps Growing Every new report means another connection, another copy of the logic, and another refresh to maintain. The effort grows with every report added. Governance That Is Hard to Enforce When reports sit in different workspaces with different owners, controlling who sees what becomes a manual, error-prone exercise. Data That Is Not Ready for What Is Next AI and advanced analytics need clean, connected data. Scattered data means every AI idea starts with a data consolidation project first. “The data was never the problem. The problem was that it lived in five places, and every system handled it differently.” What One Data Platform Really Means One data platform is not just a new database or a bigger data warehouse. It is a change in how the organization treats its data – from something each system and report manages on its own, to a shared business asset managed once, for everyone. Functionally, it comes down to four commitments: 1One place for all business data – Every source system feeds a single platform, so finance, sales, HR, and operations data sit side by side and can be connected. 2One way of processing it – Every source goes through the same standardized stages, so data is cleaned and shaped consistently no matter where it came from. 3One definition of every business rule – Business logic – how revenue is grouped, how a meeting is classified, how an employee is counted – is defined once and reused everywhere. 4One layer of governance – Access is controlled centrally by role, so the right people see the right data without each report owner managing permissions separately. Why It Matters to the Business For leadership, the value of one data platform shows up in outcomes rather than architecture. A Single Source of Truth Every report reads from the same curated data, so the numbers agree across finance, operations, and management reporting. Faster Answers, Less Rework New reports and new data sources are added through configuration, not rebuilt from scratch. Teams spend time on insight instead of plumbing. Stronger Governance by Design Centralized, role-based access means security is enforced by the platform, not by individual report owners. Lower Long-Term Complexity One pipeline and one framework replace a patchwork of tools, reducing maintenance and dependency on specific individuals. Scales With the Business Adding a new system or entity follows the same pattern, so growth does not multiply reporting complexity. A Foundation for AI Clean, connected, governed data is exactly what AI, machine learning, and process mining need to deliver reliable results. Solution Architecture Overview We built our one data platform on Azure and Databricks. Here is how it fits together, from five source systems to a single, governed Power BI workspace. How the Architecture Works Step 1: Connect the Source SystemsBusiness Central, Finance & Operations, Dynamics 365 CRM, Zoho People, and Zoho Books are registered once in a central ingestion list that tells the platform what data to bring in. … Continue reading From Multiple Data Sources to Azure Databricks: A Zero-Downtime Power BI Migration for Future AI Readiness →

Summary Most organizations implement AI in a set sequence – connect systems, clean the data, then govern and track adoption. That is the right path, but we could help ourselves by implementing AI that eases the “Clean Data” process itself. This post flips the script: instead of using AI only for insights, use it to flag what is missing, overdue or stale in your Opportunities. An example from the Sales Opportunities review portal we run at CloudFronts shows how a Pipeline Risk area instils the habit of keeping Dataverse / D365 Sales data correct, so the AI that follows is closer to accurate. Related reading: Using Dataverse MCP with Claude to Unlock Business Insights for Senior Leaders and our AI Managed Services Agreement. Table of Contents 01Summary 02Where We Are on the AI Journey 03AI For Clean Data 04Example 05Conclusion Where We Are on the AI Journey We are somewhere on the journey in implementing AI at our organization. And in this process, we often are looking to implement AI in the organization in the below sequence – Connect systems via robust integrations. Clean the data for Analytics and AI. Implement AI governance and track adoption. While this is the right path to implement AI, we stick to the plan in implementing AI. And this isn’t incorrect. However, we could help ourselves by implementing AI that promotes easing the “Clean Data” process. AI For Clean Data So, let’s flip the script for a bit – “Clean Data for AI” can start with “AI for Clean Data”. Let me explain with a use case – You are a Sales Lead at a professional services firm. You are supposed to make sure Opportunities are correctly tracked with the right probabilities, follow ups and have clean prospect data in them. Now, implement an AI that flags the data discrepancies instead of typically using AI for “AI Insights”. Let AI tell you – “Something is missing” “Something is overdue” “You have not communicated yet” “There’s no address or website for the Opportunities” “Revenue numbers or follow up dates are missing” Now most times, it might not be relevant to put this info – there can always be 5% exception in the data. However, this promotes cleaning the data that matters for the actual AI to implement by instilling good habits. Example Now, I’m running this portal for the Sales Opportunities review of the Management. I’m supposed to keep the Opportunities always updated for the management to have a true view of the pipeline and probabilities. The Sales Opportunities review portal – pipeline by quarter and Hot Opportunities, with the Pipeline Risks area running down the left. Due to busy schedule, things can fall through and the data continues to become stale and outdated. It might not show what Opportunities really are Hot or it might show some other Opportunities as Hot because I didn’t update the notes when probability dropped. So to tackle this problem, on the main pane itself – I’ve added a Pipeline Risk area. This will look at the existing data and flag me anything which should be incorrect. The Pipeline Risk area flags what looks incorrect – overdue deals, stalled engagement, accounts with no recent activity notes. Now whether it is true or not is up to me – but this puts me in a habit to make sure I always update my Dataverse / D365 Sales Opportunities correctly, so the AI Summary for Hot Opportunities improves and shows relevant data at all times. Now if you extrapolate these to bigger actions across all AI implementations of flagging incorrect data to the end user – it promotes good habits that make the intended AI to be closer to accuracy in its own non-deterministic nature. This is what is implemented at CloudFronts for our Sales efforts and similar versions are implemented for our customers using Dynamics 365 CRM/Sales for their implementations. Conclusion This might be a small trigger for a human change, but it has its compounding effects in implementing AI at your organization that directly co-relate to a production use case being a success or a failure. Human-in-the-loop is very much a reality and a necessity that we think it is. Further, the higher order of AI implementations like automated decision making can follow. Want AI That Keeps Your CRM Data Honest? If you’re exploring how to put AI on top of Dynamics 365 or Dataverse, we’d be glad to talk through where it makes sense to start. Keeping this running beyond the first use case is what our AI Managed Services Agreement is built for. Contact Us AI Managed Services Agreement Priyesh Wagh Microsoft AI ERP MVP, Practice Manager · cloudfronts.com Priyesh Wagh is a Practice Manager at CloudFronts and Microsoft AI ERP MVP. Priyesh works with his team in delivering Dynamics 365 business applications implementation to CloudFronts global customers, mainly in the US and Europe. Connect with Priyesh on LinkedIn.

MRP Batch Trigger Service Summary Planning Optimization (what most F&O teams still call MRP out of habit) normally runs on a fixed recurrence: nightly, or every few hours. That’s fine until an upstream event lands between runs and the plan needs to reflect it before the next window opens. Rather than reconstructing the entire Planning Optimization call from scratch, this post covers a smaller, safer pattern: a custom X++ service that finds the existing, already-configured batch job and flips its status to Waiting, so the batch framework picks it up on its next poll. Same job, same configuration, just triggered early. The example is drawn from an engagement with a North American truck manufacturer, where an upstream integration needed to nudge Master Planning immediately after a data load rather than wait out the scheduled recurrence. On this page 01The business trigger 02Why reuse the batch job, not rebuild the call 03Where the batch job’s RecId comes from 04The service class 05Exposing it as a callable service 06Gotchas worth knowing 07FAQs 08Conclusion The business trigger Planning Optimization is normally left alone once it’s configured: coverage groups, item coverage, and a batch recurrence tell it when to run, and most days that schedule is all anyone needs. The gap shows up when a trigger for a fresh plan doesn’t come from the calendar; it comes from another system. A large sales order import lands late, an engineering change lands mid-afternoon, or an upstream integration finishes a nightly sync on its own schedule, and the planning team needs the recalculated plan before the next window opens, not after. Manually opening Master Planning parameters and clicking “Run now” doesn’t scale when the trigger has to come from outside the ERP entirely. Why reuse the batch job, not rebuild the call Planning Optimization isn’t a simple in-process function call. The batch task hands off to an Azure-hosted optimization engine, carrying policy and configuration that already lives in Master Planning setup: coverage groups, item coverage codes, the plan itself. Reconstructing that entire call from a custom service would mean duplicating configuration the system already tracks, and keeping two copies of it in sync forever. The simpler move: find the batch job the system already runs on its recurrence, and change its status so the batch framework picks it up on the next poll instead of waiting for the scheduled time. Same job, same configuration, just triggered early. Where the batch job’s RecId comes from The service doesn’t look the batch job up by caption at runtime; captions get renamed, retranslated, or duplicated, which makes name-matching fragile. Instead, the correct job’s RecId is captured once, during setup, and stored on a custom parameters table (here, a field on ReqParameters). The trigger call then becomes a single indexed select instead of a caption search. Ops note: because the pointer is a raw RecId, it breaks silently if the batch job is ever deleted and recreated. An LCS environment refresh or a redeploy of the batch setup is enough to do it. Re-capture and re-save the RecId as part of any environment refresh checklist. The service class The method is deliberately thin: find the configured batch job, flip its status inside a transaction, and report back what happened. CFMRPOptimizationBatchTriggerService.xpp internal final class CFMRPOptimizationBatchTriggerService { public CFMRPOptBatchTriggerServiceResponseContract triggerMRPOptBatchJob() { CFMRPOptBatchTriggerServiceResponseContract response = new CFMRPOptBatchTriggerServiceResponseContract(); try { BatchJob batchJob; select firstOnly forUpdate batchJob where batchJob.RecId == ReqParameters::find().MRPOptBatchJobRefRecId; if (!batchJob.RecId) { response.parmMessage(“Planning Optimization batch job was not found.”); } else if (batchJob) { ttsbegin; batchJob.selectForUpdate(true); batchJob.Status = BatchStatus::Waiting; batchJob.update(); ttscommit; response.parmMessage(strFmt( “Planning optimization batch job found and triggered. ID: %1, Description: %2, Status: %3”, batchJob.RecId, batchJob.Caption, enum2Str(batchJob.Status))); } } catch (Exception::Error) { response.parmMessage(“Trigger failed”); } return response; } } Three things worth calling out in that order of execution: The initial select firstOnly forUpdate locates the job and prepares it for a later update, but it sits outside any transaction at that point. The real lock happens with the selectForUpdate(true) call just before ttsbegin, which is what actually matters for correctness under concurrent triggers. Flipping Status to Waiting is the entire “trigger.” Nothing here talks to the Planning Optimization engine directly; that’s the batch framework’s job once it sees a waiting task. The response contract carries a single human-readable message, which is enough for a calling system to log success or failure without needing to parse the batch job’s internal state itself. Exposing it as a callable service The class itself is just X++. Making it callable from outside the ERP is a standard AOT step: 1Add an AOT Service node referencing this class and the triggerMRPOptBatchJob method. 2Add the service to a Service Group and deploy. F&O exposes it over the standard integration endpoint once deployed, callable from an integration platform or middleware without any custom endpoint code. 3Have the calling system read parmMessage to confirm the job was actually found and flipped, rather than treating a successful call as proof that MRP ran. The trigger is fire-and-forget from the batch engine’s side. Gotchas worth knowing “Waiting” is not “running now.” The status change queues the job for the batch server’s next poll, typically seconds to a couple of minutes later depending on batch server load, not a synchronous MRP run. Don’t build a caller that blocks waiting for a result. The catch block swallows the real error. catch (Exception::Error) returns a flat “Trigger failed” with no diagnostic detail retained. That’s fine for a demo; in production it means the caller, and whoever gets paged, has no idea why it failed. Worth extending to log the actual exception before returning the generic message. Retriggering a running job is harmless, but a symptom. Flipping an already-Executing job back to Waiting doesn’t start a second concurrent run. If a caller is doing that repeatedly in a tight retry loop, though, it’s usually a sign the caller isn’t checking the response message before retrying. “A trigger service doesn’t need to reimplement what Master Planning already knows how to run. It only needs to … Continue reading How a Leading North American Commercial Vehicle Manufacturer Triggers MRP On Demand Using a Custom X++ Service in Dynamics 365 Finance & Operations →

01Summary Project-based businesses often run their projects in Dynamics 365 Project Operations and their finance in Dynamics 365 Business Central. The two systems do not talk to each other out of the box, so every customer, project, timesheet, expense and invoice ends up being typed into both, and the numbers finance reports on are always a step behind the project teams. CloudFronts built an integration that closes this gap using Dataverse plugins: small pieces of C# code that run inside Project Operations every time a record is saved. When someone creates a customer, sets up a project, approves a timesheet or confirms an invoice, the plugin sends that record straight to the matching Business Central web service and writes the Business Central number back onto it. Before material is used on a project, it looks up how much stock Business Central holds at that location. Anything that fails is saved in an Error Log with the exact data that was sent. To keep the examples concrete, this post follows a sample scenario: Wexford County Council orders a satellite broadband installation at its Castlemoyle and Bunclody water treatment sites, and the project runs from the first lead to the final invoice across both systems. Table of Contents 01Summary→ 02Business Challenges→ 03Solution Overview→ 04Technical Approach→ 05Business Impact→ 06Conclusion→ 02Business Challenges Project Operations and Business Central each work well on their own. The trouble is the gap between them: nothing entered in Project Operations reaches Business Central unless someone types it in again. Without an integration, teams run into the same problems: Everything is entered twice. A new customer or project is created in Project Operations, then created again in Business Central. Every later change has to be repeated by hand. Master data drifts apart. Countries, postcodes, currencies, payment terms, dimensions and work types have to match in both systems. When one side changes and the other does not, records fail to post. Approved work reaches finance late. Approved timesheets, expenses and material only arrive in Business Central after someone exports and imports them, so project costs in finance are always behind. Material is used without checking stock. Site teams log material against a project without knowing whether Business Central actually has it at that location. Invoices are keyed twice. A confirmed project invoice has to be rebuilt in Business Central, line by line, before finance can post it. Errors are hard to trace. When a record does not match, nobody can see what was sent or why Business Central rejected it. 03Solution Overview CloudFronts built one main plugin, RequestProcessor, and registered it on every Project Operations table that finance needs. Two small helper plugins handle the stock check for material. Whenever one of those records is created, updated or deleted, Dataverse runs the plugin. The plugin works out which table the record came from, turns it into the shape Business Central expects, and sends it to the matching Business Central web service. When Business Central replies, the plugin stores the Business Central number on the Project Operations record, such as the BC customer number or the project code. Next time the record changes, the plugin uses that number to update the same record in Business Central instead of creating a new one. All the settings the plugin needs, such as where to sign in, which web service to call for each table, and which user is the integration user, live in a single Integration Configuration record in Dataverse. Moving from a test company to the live one is a change to that record, not to the code. ⓘKey terms, in plain words Dataverse plugin: C# code that Dataverse runs automatically when a record is saved, like a trigger in a database. Business Central web service: an address in Business Central that accepts records from other systems, one for customers, one for projects, and so on. Project Journal: where costs are recorded against a project in Business Central before they are posted. Project Planning Lines: the budget of a project in Business Central. ⓘWhy a plugin instead of Power Automate? A cloud flow could copy simple records, but this integration covers 20 tables with detailed mapping rules for each one. In a plugin, that logic lives in one C# project that can be versioned, reviewed and tested like any other code. The plugin runs the moment the record is saved, only on the tables and messages it is registered for, and it ships in the same Dataverse solution as the rest of the Project Operations customisation. 04Technical Approach How It Works Every save takes the same path through the plugin: A record is saved in Project OperationsFor example, the project manager approves a week of time entries on the Wexford County Council broadband project. RequestProcessor loads its settingsIt reads the Integration Configuration record. If the record is missing, the plugin stops quietly instead of failing the user’s save. It skips its own changesIf the record was last modified by the integration user, the plugin stops. This keeps it from running again on the Business Central number it has just written back. The handler for that table maps the recordIt checks the record’s status, so only approved entries or confirmed invoices go further, and copies the fields into the JSON shape Business Central expects. Business Central creates or updates the recordPOST creates a new record; PUT updates the one already linked by its Business Central number. The result is savedOn success, the Business Central number is written back onto the Project Operations record. On failure, an Error Log record is created with the details. What Moves Between the Systems The plugin handles 20 Project Operations tables. They fall into five groups, in the order a project normally runs. Group Saved in Project Operations Created in Business Central When It Is Sent Customers Account Customer, or Vendor when the account type is Vendor Create and update; a delete blocks the record in BC instead of removing it Customers Contact Contact Create, update and delete … Continue reading How We Built a Project Operations to Business Central Integration Using Dataverse Plugins →

Summary Most project businesses we work with have the same quiet problem. The project team plans and tracks work in Dynamics 365 Project Operations. The finance team bills, buys and closes the books in Dynamics 365 Business Central. Everything the project team decides has to be typed again by finance. The two teams spend their week checking each other’s numbers. At CloudFronts we closed that gap with plugins: small automatic helpers that sit inside Project Operations and act the moment someone saves a record. When a project, a plan, a timesheet or an invoice is saved, the helper creates the matching record in Business Central and writes the Business Central reference back on the project. This integration is available as the PO-BC Integration Module 2.0 on Microsoft Marketplace. To show how this works in practice, we ran a real example through our demo environment: CloudFronts – Smart Office Rollout, Mumbai, a short project to fit out a new office floor. Every screenshot in this post comes from that one project. Table of Contents Summary→ Business Challenges→ The Idea in Plain Words→ Walkthrough: The Mumbai Office Rollout→ What Moves, and When→ The Safety Nets→ What We Learned Building It→ Business Impact / Key Takeaways→ Questions We Get Asked→ Conclusion / Final Thoughts→ Call to Action / Connect With Us→ Business Challenges Picture the Mumbai office rollout without any connection between the two systems. Monday. The project manager sets up the project, splits it into four tasks and plans 104 hours of work in Project Operations. Finance is told about it in an email. Tuesday. Finance creates the same project in Business Central, retypes the four tasks, and builds a budget from a spreadsheet the project manager sent over. One task name is spelt differently. Nobody notices. Wednesday. The plan changes: cabling needs an extra day. Project Operations is updated. The budget in Business Central is not. Thursday. Twenty desks are taken from the warehouse for the new floor. The site team records it in Project Operations. Business Central still believes the desks are on the shelf. Friday. Finance asks why the project margin looks wrong. Two people spend the afternoon comparing screens. None of this is anyone’s fault. Each system is doing its job. They just do not talk to each other. The Idea in Plain Words A plugin is a small piece of code that lives inside Project Operations and wakes up at a specific moment, for example when a project is saved or a timesheet is approved. Ours does three things each time it wakes up: It reads what just changedThe project name, the customer, the task, the hours, the item and quantity: whatever finance would otherwise have to retype. It creates or updates the same record in Business CentralIt signs in to Business Central with its own dedicated account, not a person’s login, so it keeps working when people change roles or leave. It writes the answer backBusiness Central replies with its own reference, such as a project number or an invoice number. That reference is saved on the Project Operations record, so both teams can always find the matching record in the other system. 💡Why a plugin and not a scheduled sync? A scheduled sync runs every hour or every night and moves whatever has changed. A plugin acts on the exact save, so Business Central is updated within seconds, and only the record that changed is sent. It is also packaged with the rest of the Project Operations setup, so moving it from the test system to the live one is a single, repeatable step. Walkthrough: The Mumbai Office Rollout Here is the same week again, this time with the integration switched on. The customer is CloudFronts Technologies, already known to Business Central as customer C00310. The work is 40 new workstations, meeting-room screens and office Wi-Fi. The customer account, integrated to Business Central with its customer number sent back. Step 1: The Project Manager Creates the Project, Once The project manager creates the project in Project Operations with a name, the customer, a start date of 12 October and a finish date in December. The project code is left blank because nobody knows it yet. A few seconds after saving, the code J00700 appears in the Project Code field. That number came back from Business Central. The project integrated to Business Central. The project code J00700 was filled in automatically. Step 2: The Tasks Follow The project manager adds four tasks in the project plan: Site Survey and Floor Plan, Network Cabling and Wi-Fi, Workstation and Screen Installation, and Testing and Handover. Each one is created under project J00700 in Business Central with the same name and dates, numbered 1272 to 1275. Finance did not open anything. Step 3: The Plan Becomes the Budget Next, the project manager assigns a named person to each task: 16 hours for the survey, 40 for cabling, 32 for installation and 16 for testing and handover. The integration turns that plan into budget lines in Business Central, one line per working day per person, so finance sees not only how much work is planned but when it falls. Weekends are skipped automatically. Resource assignments from Project Operations, turned into daily planning lines in Business Central. ⓘWhy one line per day? A single line of "104 hours" tells finance the total but nothing about timing. Daily lines let finance see cost landing in October versus November, which matters at month end. If the plan changes, the same lines are updated, not duplicated. Step 4: Real Work and Real Material Arrive as Actuals On 12 October, the consultant logs a day on the site survey: "Walk-through of the new floor; desk layout and cable routes agreed with facilities." A week later, the site team records 20 ATHENS desks taken from the Main Warehouse for the installation task. The integration does not send rough drafts. Time and material only go to Business Central once they are submitted for approval, and the … Continue reading No More Retyping: How We Connected Project Operations and Business Central with Plugins →